Intel SGX Remote Attestation is not sufficient

Intel SGX enclaves provide hardware enforced confidentiality and integrity guarantees for running pure computations (i.e., OS-level side-effect-free code) in the cloud environment. In addition, SGX remote attestation enables enclaves to prove that a claimed enclave is indeed running inside a genuine SGX hardware and not some (adversary controlled) SGX simulator. Since cryptographic protocols do not compose well [Cra96, Can00, HS11], especially when run concurrently, SGX remote attestation is only a necessary pre-condition for securely instantiating an enclave. In practice, one needs to analyze all the different interacting enclaves as a single protocol and make sure that no sub-computation of the protocol can be simulated outside of the enclave. In this paper we describe protocol design problems under (a) sequential-composition, (b) concurrentcomposition, and (c) enclave state malleability that must be taken into account while designing new enclaves. We analyze Intel provided EPID [BL10] Provisioning and Quoting enclave [JSR+16] and report our (largely positive) findings. We also provide details about how SGX uses EPID Group Signatures and report (largely negative) results about claimed anonymity guarantees.